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Abstract 


This document reviews the existing mechanisms for site renumbering 
for both IPv4 and IPv6, and it identifies operational issues with 
those mechanisms. It also summarises current technical proposals for 
additional mechanisms. Finally, there is a gap analysis identifying 
possible areas for future work. 
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1. Introduction 


In early 1996, the IAB published a short RFC entitled "Renumbering 
Needs Work" [RFC1900], which the reader is urged to review before 
continuing. Almost ten years later, the IETF published "Procedures 
for Renumbering an IPv6 Network without a Flag Day" [RFC4192]. A few 
other RFCs have touched on router or host renumbering: [RFC1916], 
[RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076]. 


In fact, since 1996, a number of individual mechanisms have become 
available to simplify some aspects of renumbering. The Dynamic Host 
Configuration Protocol (DHCP) is available for IPv4 [RFC2131] and 
IPv6 [RFC3315]. IPv6 includes Stateless Address Autoconfiguration 
(SLAAC) [RFC4862], and this includes Router Advertisements (RAs) that 
include options listing the set of active prefixes on a link. The 
Point-to-Point Protocol (PPP) [RFC1661] also allows for automated 
address assignment for both versions of IP. 


Despite these efforts, renumbering, especially for medium to large 
sites and networks, is widely viewed as an expensive, painful, and 
error-prone process, and is therefore avoided by network managers as 
much as possible. Some would argue that the very design of IP 
addressing and routing makes automatic renumbering intrinsically 
impossible. In fact, managers have an economic incentive to avoid 
having to renumber, and many have resorted to private addressing and 
Network Address Translation (NAT) as a result. This has the highly 
unfortunate consequence that any mechanisms for managing the scaling 
problems of wide-area (BGP4) routing that require occasional or 
frequent site renumbering have been consistently dismissed as 
unacceptable. But none of this means that we can duck the problem, 
because as explained below, renumbering is sometimes unavoidable. 
This document aims to explore the issues behind this problem 
statement, especially with a view to identifying the gaps and known 
operational issues. 


It is worth noting that for a very large class of users, renumbering 
is not in fact a problem of any significance. A domestic or small 
office user whose device operates purely as a client or peer-to-peer 
node is in practice renumbered at every restart (even if the address 
assigned is often the same). A user who roams widely with a laptop 
or pocket device is also renumbered frequently. Such users are not 
concerned with the survival of very long-term application sessions 
and are in practice indifferent to renumbering. Thus, this document 
is mainly concerned with issues affecting medium to large sites. 
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There are numerous reasons why such sites might need to renumber in a 
planned fashion, including: 


o Change of service provider, or addition of a new service provider, 
when provider-independent addressing is not an option. 


o A service provider itself has to renumber. 
o Change of site topology (i.e., subnet reorganisation). 


o Merger of two site networks into one, or split of one network into 
two or more parts. 


o During IPv6 deployment, change of IPv6 access method (e.g., from 
tunneled to native). 


The most demanding case would be unplanned automatic renumbering, 
presumably initiated by a site border router, for reasons connected 
with wide-area routing. There is already a degree of automatic 
renumbering for some hosts, e.g., IPv6 "privacy" addresses [RFC4941]. 


It is certainly to be expected that as the pressure on IPv4 address 
space intensifies in the next few years, there will be many attempts 
to consolidate usage of addresses so as to avoid wastage, as part of 
the "end game" for IPv4, which necessarily requires renumbering of 
the sites involved. However, strategically, it is more important to 
implement and deploy techniques for IPv6 renumbering, so that as IPv6 
becomes universally deployed, renumbering becomes viewed as a 
relatively routine event. In particular, some mechanisms being 
considered to allow indefinite scaling of the wide-area routing 
system might assume site renumbering to be a straightforward matter. 


There is work in progress that, if successful, would eliminate some 
of the motivations for renumbering. In particular, some types of 
solutions to the problem of scalable routing for multihomed sites 
would likely eliminate both multihoming and switching to another ISP 
as reasons for site renumbering. 


Several proposed identifier/locator split schemes provide good 
examples, including at least Identifier Locator Network Protocol 
[ILNP], Locator/ID Separation Protocol [LISP], and Six/One [SIX-ONE] 
(in alphabetical order). The recent discussion about IPv6 Network 
Address Translation (IPv6 NAT) provides a separate example [NAT66]. 
While remaining highly contentious, this approach, coupled with 
unique local addresses or a provider-independent address prefix, 
would appear to eliminate some reasons for renumbering in IPv6. 
However, even if successful, such solutions will not eliminate all of 
the reasons for renumbering. This document does not take any 
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position about development or deployment of protocols or technologies 
that would make long-term renumbering unnecessary, but rather deals 
with practical cases where partial or complete renumbering is 
necessary in today’s Internet. 


IP addresses do not have a built-in lifetime. Even when an address 
is leased for a finite time by DHCP or SLAAC, or when it is derived 
from a DNS record with a finite time to live (TTL) value, this 
information is unavailable to applications once the address has been 
passed to an upper layer by the socket interface. Thus, a 
renumbering event is almost certain to be an unpredictable surprise 
from the point of view of any application software using the address. 
Many of the issues listed below derive from this fact. 


Existing Host-Related Mechanisms 
1. DHCP 


At a high level, DHCP [RFC2131] [RFC3315] offers similar support for 
renumbering for both versions of IP. A host requests an address when 
it starts up, the request might be delivered to a local DHCP server 
or via a relay to a central server, and if all local policy 
requirements are met, the server will provide an address with an 
associated lifetime, and various other network-layer parameters (in 
particular, the subnet mask and the default router address). 


From an operational viewpoint, the interesting aspect is the local 


policy. Some sites require pre-registration of MAC (Media Access 
Control) addresses as a security measure, while other sites permit 
any MAC address to obtain an IP address. Similarly, some sites use 


DHCP to provide the same IP address to a given MAC address each time 
(this is sometimes called "Static DHCP"), while other sites do not 
(this is sometimes called "Dynamic DHCP"), and yet other sites use a 
combination of these two modes where some devices (e.g., servers, 
Voice over IP (VoIP) handsets) have a relatively static IP address 
that is provisioned via DHCP while other devices (e.g., portable 
computers) have a different IP address each time they connect to the 
network. As an example, many universities in the United States and 
United Kingdom require MAC address registration of faculty, staff, 
and student devices (including handheld computers with wireless 
connections). 


These policy choices interact strongly with whether the site has what 
might be called "strong" or "weak" asset management. At the strong 
extreme, a site has a complete database of all equipment allowed to 
be connected, certainly containing the MAC address(es) for each host, 
as well as other administrative information of various kinds. Sucha 
database can be used to generate configuration files for DHCP, DNS, 
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and any access control mechanisms that might be in use. For example, 
only certain MAC addresses might be allowed to get an IP address on 
certain subnets. At the weak extreme, a site has no asset 
management, any MAC address may get a first-come first-served IP 
address on any subnet, and there is no network-layer access control. 


The IEEE 802.1X standard [IEEE.802-1X] [IEEE.802-1X-REV] specifies a 
connection mechanism for wired/wireless Ethernet that is often 
combined with DHCP and other mechanisms to form, in effect, a network 
login. Using such a network login, the user of a device newly 
connecting to the network must provide both identity and 
authentication before being granted access to the network. As part 
of this process, the network control point will often configure the 
point of network connection for that specific user with a range of 
parameters -- such as Virtual LAN (VLAN), Access Control Lists 
(ACLs), and Quality-of-Service (QoS) profiles. Other forms of 
network login also exist, often using an initial web page for user 
identification and authentication. The latter approach is commonly 
used in hotels or cafes. 


In principle, a site that uses DHCP can renumber its hosts by 
reconfiguring DHCP for the new address range. The issues with this 
are discussed below. 


2.2. IPv6 Stateless Address Autoconfiguration 


SLAAC, although updated recently [RFC4862], was designed prior to 
DHCPv6 and was intended for networks where unattended automatic 
configuration was preferred. Ignoring the case of an isolated 
network with no router, which will use link-local addresses 
indefinitely, SLAAC follows a bootstrap process. Each host first 
gives itself a link-local address, and then needs to receive a link- 
local multicast Router Advertisement (RA) [RFC4861] that tells it the 
routeable subnet prefix and the address(es) of the default router(s). 
A node may either wait for the next regular RA or solicit one by 
sending a link-local multicast Router Solicitation. Knowing the link 
prefix from the RA, the node may now configure its own address. 

There are various methods for this, of which the basic one is to 
construct a unique 64-bit identifier from the interface’s MAC 
address. 


We will not describe here the IPv6 processes for Duplicate Address 
Detection (DAD), Neighbour Discovery (ND), and Neighbour 
Unreachability Discovery (NUD). Suffice it to say that they work, 
once the initial address assignment based on the RA has taken place. 
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The contents of the RA message are clearly critical to this process 
and its use during renumbering. An RA can indicate more than one 
prefix, and more than one router can send RAs on the same link. For 
each prefix, the RA indicates two lifetimes: "preferred" and "valid". 
Addresses derived from this prefix must inherit its lifetimes. When 
the valid lifetime expires, the prefix is dead and the derived 
address must not be used any more. When the preferred lifetime is 
expired (or set to zero) the prefix is deprecated, and must not be 
used for any new sessions. Thus, setting a preferred lifetime that 
is zero or finite is SLAAC’s warning that renumbering will occur. 
SLAAC assumes that the new prefix will be advertised in parallel with 
the deprecated one, so that new sessions will use addresses 
configured under the new prefix. 


2.3. IPv6 ND Router/Prefix Advertisements 


With IPv6, a Router Advertisement not only advertises the 
availability of an upstream router, but also advertises routing 
prefix(es) valid on that link (subnetwork). Also, the IPv6 RA 
message contains a flag indicating whether or not the host should use 
DHCPv6 to configure. If that flag indicates that the host should use 
DHCPv6, then the host is not supposed to autoconfigure itself as 
outlined in Section 2.2. However, there are some issues in this 
area, described in Section 5.1.1. 


In an environment where a site has more than one upstream link to the 
outside world, the site might have more than one valid routing 
prefix. In such cases, typically all valid routing prefixes within a 
site will have the same prefix length. Also, in such cases, it might 
be desirable for hosts that obtain their addresses using DHCPv6 to 
learn about the availability of upstream links dynamically, by 
deducing from periodic IPv6 RA messages which routing prefixes are 
currently valid. This application seems possible within the IPv6 
Neighbour Discovery architecture, but does not appear to be clearly 
specified anywhere. So, at present, this approach for hosts to learn 
about availability of new upstream links or loss of prior upstream 
links is unlikely to work with currently shipping hosts or routers. 


2.4. PPP 


"The Point-to-Point Protocol (PPP)" [RFC1661] includes support for a 
Network Control Protocol (NCP) for both IPv4 and IPv6. 


For IPv4, the NCP is known as IPCP [RFC1332] and allows explicit 
negotiation of an IP address for each end. PPP endpoints acquire 
(during IPCP negotiation) both their own address and the address of 
their peer, which may be assumed to be the default router if no 
routing protocol is operating. Renumbering events arise when IPCP 
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negotiation is restarted on an existing link, when the PPP connection 
is terminated and restarted, or when the point-to-point medium is 
reconnected. Peers may propose either the local or remote address or 
require the other peer to do so. Negotiation is complete when both 
peers are in agreement. In practice, if no routing protocol is used, 
as in a subscriber/provider environment, then the provider proposes 
both addresses and requires the subscriber either to accept the 
connection or to abort. Effectively, the subscriber device is 
renumbered each time it connects for a new session. 


For IPv6, the NCP is IP6CP [RFC5072] and is used to configure an 
interface identifier for each end, after which link-local addresses 
may be created in the normal way. In practice, each side can propose 
its own identifier and renegotiation is only necessary when there is 
a collision, or when a provider wishes to force a subscriber to use a 
specific interface identifier. Once link-local addresses are 
assigned and IP6CP is complete, automatic assignment of global scope 
addresses is performed by the same methods as with multipoint links, 
i.e., either SLAAC or DECPv6. Again, in a subscriber/provider 
environment, this allows renumbering per PPP session. 


2.5. DNS Configuration 


A site must provide DNS records for some or all of its hosts, and of 
course these DNS records must be updated when hosts are renumbered. 
Most sites will achieve this by maintaining a DNS zone file (ora 
database from which it can be generated) and loading this file into 
the site’s DNS server(s) whenever it is updated. As a renumbering 
tool, this is clumsy but effective. Clearly perfect synchronisation 
between the renumbering of the host and the updating of its A or AAAA 
record is impossible. An alternative is to use Secure Dynamic DNS 
Update [RFC3007], in which a host informs its own DNS server when it 
receives a new address. 


There are widespread reports that the freely available BIND DNS 
software (which is what most UNIX hosts use), Microsoft Windows (XP 
and later), and Mac OS X all include support for Secure Dynamic DNS 
Update. So do many home gateways. Further, there are credible 
reports that these implementations are interoperable when configured 
properly ([DNSBOOK] p. 228 and p. 506). 


Commonly used commercial DNS and DHCP servers (e.g., Windows Server) 
often are deployed with Secure Dynamic DNS Update also enabled. In 
some cases, merely enabling both the DNS server and the DHCP server 
might enable Secure Dynamic DNS Update as an automatic side effect 
([DNSBOOK] p. 506). So in some cases, sites might have deployed 
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Secure Dynamic DNS Update already, without realising it. An 
additional enhancement would be for DHCP clients to implement support 
for the "Client FODN" option (Option 81). 


Since address changes are usually communicated to other sites via the 
DNS, the latter's security is essential for secure renumbering. The 
Internet security community believes that the current DNS Security 
(DNSsec) and Secure Dynamic DNS Update specifications are 
sufficiently secure and has been encouraging DNSsec deployment 
([REC3007] [RFC4033] [RFC4034] [RFC4035]). 


As of this writing, there appears to be significantly more momentum 
towards rapid deployment of DNS Security standards in the global 
public Internet than previously. Several country-code Top-Level 
Domains (ccTLDs) have already deployed signed TLD root zones (e.g., 
Sweden's .SE). Several other TLDs are working to deploy signed TLD 
root zones by published near-term deadlines (e.g., .GOV, .MIL). In 
fact, it is reported that .GOV has been signed operationally since 
early February 2009. It appears likely that the DNS-wide root zone 
will be signed in the very near future. See, for example, 
<http://www.dnssec-deployment.org/> and 
<http://ww.ntia.doc.gov/DNS/DNSSEC.html>. 


2.6. Dynamic Service Discovery 


The need for hosts to contain pre-configured addresses for servers 
Can be reduced by deploying the Service Location Protocol (SLP). For 
some common services, such as network printing, SLP can therefore be 
an important tool for facilitating site renumbering. See [RFC2608], 
[RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832]. 


Multicast DNS (mDNS) and DNS Service Discovery are already widely 
deployed in BSD, Linux, Mac OS X, UNIX, and Windows systems, and are 
also widely used for both link-local name resolution and for DNS- 
based dynamic service discovery [MDNS] [DNSSD]. In many 
environments, the combination of mDNS and DNS Service Discovery 
(e.g., using SRV records [RFC3958]) can be important tools for 
reducing dependency on configured addresses. 


3. Existing Router-Related Mechanisms 
3.1. Router Renumbering 
Although DHCP was originally conceived for host configuration, it can 


also be used for some aspects of router configuration. The DHCPv6 
Prefix Delegation options [RFC3633] are intended for this. For 
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example, DHCPv6 can be used by an ISP to delegate or withdraw a 
prefix for a customer’s router, and this can be cascaded throughout a 
site to achieve router renumbering. 


An ICMPv6 extension to allow router renumbering for IPv6 is specified 
in [RFC2894], but there appears to be little experience with it. It 
is not mentioned as a useful mechanism by [RFC4192]. 


[RFC4191] extends IPv6 router advertisements to convey default router 
preferences and more-specific routes from routers to hosts. This 
could be used as an additional tool to convey information during 
renumbering, but does not appear to be used in practice. 


[CPE] requires that a customer premises router use DHCPv6 to obtain 
an address prefix from its upstream ISP and use IPv6 RA messages to 
establish a default IPv6 route (when IPv6 is in use). 


4. Existing Multi-Addressing Mechanism for IPv6 


IPv6 was designed to support multiple addresses per interface and 
multiple prefixes per subnet. As described in [RFC4192], this allows 
for a phased approach to renumbering (adding the new prefix and 
addresses before removing the old ones). 


As an additional result of the multi-addressing mechanism, a site 
might choose to use Unique Local Addressing (ULA) [RFC4193] for all 
on-site communication, or at least for all communication with on-site 
servers, while using globally routeable IPv6 addresses for all off- 
site communications. It would also be possible to use ULAs for all 
on-site network management purposes, by assigning ULAs to all 
devices. This would make these on-site activities immune to 
renumbering of the prefix(es) used for off-site communication. 
Finally, ULAs can be safely shared with peer sites with which there 
is a VPN connection, which cannot be done with ambiguous IPv4 
addresses [RFC1918]; such VPNs would not be affected by renumbering. 


The IPv6 model also includes "privacy" addresses that are constructed 
with pseudo-random interface identifiers to conceal actual MAC 
addresses [RFC4941]. This means that IPv6 stacks and client 
applications already need to be agile enough to handle frequent IP 
address changes (e.g., in the privacy address), since in a privacy- 
sensitive environment the address lifetime likely will be rather 
short. 
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5. 


Operational Issues with Renumbering Today 


For IPv6, a useful description of practical aspects was drafted in 
[THINK], as a complement to [RFC4192]. As indicated there, a primary 
requirement is to minimise the disruption caused by renumbering. 

This applies at two levels: disruption to site operations in general 
and disruption to individual application sessions in progress at the 


moment of renumbering. In the IPv6 case, the intrinsic ability to 
overlap use of the old and new prefixes greatly mitigates disruption 
to ongoing sessions, as explained in [RFC4192]. This approach is in 


practice excluded for IPv4, largely because IPv4 lacks a Stateless 
Address Autoconfiguration (SLAAC) mechanism. 


.1. Host-Related Issues 


.1.1. Network-Layer Issues 


For IPv4, the vast majority of client systems (PCs, workstations, and 
handheld computers) today use DHCP to obtain their addresses and 
other network-layer parameters. DHCP provides for lifetimes after 
which the address lease expires. So it should be possible to devise 
an operational procedure in which lease expiry coincides with the 
moment of renumbering (within some margin of error). In the simplest 
case, the network administrator just lowers all DHCP address lease 
lifetimes to a very short value (e.g., a few minutes). It does this 
long enough before a site-wide change that each node will 
automatically pick up its new IP address within a few minutes of the 
renumbering event. In this case, it would be the DHCP server itself 
that automatically accomplishes client renumbering, although this 
would cause a peak of DHCP traffic and therefore would not be 
instantaneous. DHCPv6 could accomplish a similar result. 


The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203]. 

This is specifically unicast-only; a DHCP client must discard a 
multicast FORCERENEW. This could nevertheless be used to trigger the 
renumbering process, with the DHCP server cycling through all its 
clients issuing a FORCERENEW to each one. DHCPv6 has a similar 
feature, i.e., a unicast RECONFIGURE message, that can be sent to 
each host to inform it to check its DHCPv6 server for an update. 
These two features do not appear to be widely used for bulk 
renumbering purposes. 


Procedures for using a DHCP approach to site renumbering will be very 
different depending on whether the site uses strong or weak asset 
management. With strong asset management, and careful operational 
planning, the subnet addresses and masks will be updated in the 
database, and a script will be run to regenerate the DHCP MAC-to-IP 
address tables and the DNS zone file. DHCP and DNS timers will be 
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set temporarily to small values. The DHCP and DNS servers will be 
fed the new files, and as soon as the previous DHCP leases and DNS 
TTLs expire, everything will follow automatically, as far as the host 
IP layer is concerned. In contrast, with weak asset management, and 
a casual operational approach, the DHCP table will be reconfigured by 
hand, the DNS zone file will be edited by hand, and when these 
configurations are installed, there will be a period of confusion 
until the old leases and TTLs expire. The DHCP FORCERENEW or 
RECONFIGURE messages could shorten this confusion to some extent. 


DHCP, particularly for IPv4, has acquired a very large number of 
additional capabilities, with approximately 170 options defined at 
the time of this writing. Although most of these do not carry IP 
address information, some do (for example, options 68 through 76 all 
carry various IP addresses). Thus, renumbering mechanisms involving 
DHCP have to take into account more than the basic DHCP job of 
leasing an address to each host. 


SLAAC is much less overloaded with options than DHCP; in fact, its 
only extraneous capability is the ability to convey a DNS server 
address. Using SLAAC to force all hosts on a site to renumber is 
therefore less complex than DHCP, and the difference between strong 
and weak asset management is less marked. The principle of 
synchronising the SLAAC and DNS updates, and of reducing the SLAAC 
lease time and DNS TTL, does not change. 


We should note a currently unresolved ambiguity in the interaction 
between DHCPv6 and SLAAC from the host's point of view. RA messages 
include a 'Managed Configuration” flag known as the M bit, which is 
supposed to indicate that DHCPv6 is in use. However, it is 
unspecified whether hosts must interpret this flag rigidly (i.e., may 
or must only start DHCPv6 if it is set, or if no RAs are received) or 
whether hosts are allowed or are recommended to start DHCPv6 by 
default. An added complexity is that DHCPv6 has a ’stateless’ mode 
[RFC3736] in which SLAAC is used to obtain an address, but DHCPv6 is 
used to obtain other parameters. Another flag in RA messages, the 
"Other configuration’ or O bit, indicates this. 


Until this ambiguous behaviour is clearly resolved by the IETF, 
operational problems are to be expected, since different host 
operating systems have taken different approaches. This makes it 
difficult for a site network manager to configure systems in such a 
way that all hosts boot in a consistent way. Hosts will start SLAAC, 
if so directed by appropriately configured RA messages. However, if 
one operating system also starts a DHCPv6 client by default, and 
another one starts it only when it receives the M bit, systematic 
address management is impeded. 
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Also, it should be noted that on an isolated LAN, neither RA nor 
DHCPv6 responses will be received, and the host will remain with only 
its self-assigned link-local address. One could also have a 
situation where a multihomed network uses SLAAC for one address 
prefix and DHCPv6 for another, which would clearly create a risk of 
inconsistent host behaviour and operational confusion. 


Neither the SLAAC approach nor DHCP without pre-registered MAC 
addresses will work reliably in all cases of systems that are 
assigned fixed IP addresses for practical reasons. Of course, even 
systems with static addressing can be configured to use DHCP to 
obtain their IP address(es). Such use of "Static DHCP" usually will 
ease site renumbering when it does become necessary. However, in 
other cases, manual or script-driven procedures, likely to be site- 
specific and definitely prone to human error, are needed. If a site 
has even one host with a fixed, manually configured address, 
completely automatic host renumbering is very likely to be 
impossible. 


The above assumes the use of typical off-the-shelf hardware and 
software. There are other environments, often referred to as 
embedded systems, where DHCP or SLAAC might not be used and even 
configuration scripts might not be an option; for example, fixed IP 
addresses might be stored in read-only memory, or even set up using 
Dual In-Line Package (DIP) switches. Such systems create special 
problems that no general-purpose solution is likely to address. 


5.1.2. Transport-Layer Issues 


TCP connections and UDP flows are rigidly bound to a given pair of IP 
addresses. These are included in the checksum calculation, and there 
is no provision at present for the endpoint IP addresses to change. 
It is therefore fundamentally impossible for the flows to survive a 
renumbering event at either end. From an operational viewpoint, this 
means that a site that plans to renumber itself is obliged either to 
follow the overlapped procedure described in [RFC4192] or to announce 
a site-wide outage for the renumbering process, during which all user 


sessions will fail. In the case of IPv4, overlapping of the old and 
new addresses is unlikely to be an option, and in any case is not 
commonly supported by software. Therefore, absent enhancements to 


TCP and UDP to enable dynamic endpoint address changes (for example, 
[HANDLEY]), interruptions to TCP and UDP sessions seem inevitable if 
renumbering occurs at either session endpoint. The same appears to 

be true of Datagram Congestion Control Protocol (DCCP) [RFC4340]. 
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In contrast, Stream Control Transmission Protocol (SCTP) already 
supports dynamic multihoming of session endpoints, so SCTP sessions 
ought not be adversely impacted by renumbering the SCTP session 
endpoints [RFC4960] [RFC5061]. 


5.1.3. DNS Issues 


The main issue is whether the site in question has a systematic 
procedure for updating its DNS configuration. If it does, updating 
the DNS for a renumbering event is essentially a clerical issue that 
must be coordinated as part of a complete plan, including both 
forward and reverse mapping. As mentioned in [RFC4192], the DNS TTL 
will be manipulated to ensure that stale addresses are not cached. 
However, if the site uses a weak asset management model in which DNS 
updates are made manually on demand, there will be a substantial 
period of confusion and errors will be made. 


There are anecdotal reports that many small user sites do not even 
maintain their own DNS configuration, despite running their own web 
and email servers. They point to their ISP’s resolver, request the 
ISP to install DNS entries for their servers, but operate internally 
mainly by IP address. Thus, renumbering for such sites will require 
administrative coordination between the site and its ISP(s), unless 
the DNS servers in use have Secure Dynamic DNS Update enabled. Some 
commercial DNS service firms include Secure Dynamic DNS Update as 
part of their DNS service offering. 


It should be noted that DNS entries commonly have matching Reverse 
DNS entries. When a site renumbers, these reverse entries will also 
need to be updated. Depending on a site’s operational arrangements 
for DNS support, it might or might not be possible to combine forward 
and reverse DNS updates in a single procedure. 


5.1.4. Application-Layer Issues 


Ideally, we would carry out a renumbering analysis for each 
application protocol. To some extent, this has been done, in 
[RFC3795]. This found that 34 out of 257 Standards-Track or 
Experimental application-layer RFCs had explicit address 
dependencies. Although this study was made in the context of IPv4 to 
IPv6 transition, it is clear that all these protocols might be 
sensitive to renumbering. However, the situation is worse, in that 
there is no way to discover by analyzing specifications whether an 
actual implementation is sensitive to renumbering. Indeed, such 
analysis might be quite impossible in the case of proprietary 
applications. 
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The sensitivity depends on whether the implementation stores IP 
addresses in such a way that it might refer back to them later, 
without allowing for the fact that they might no longer be valid. In 
general, we can assert that any implementation is at risk from 
renumbering if it does not check that an address is valid each time 
it opens a new communications session. This could be done, for 
example, by knowing and respecting the relevant DNS TTL, or by 
resolving relevant Fully-Qualified Domain Names (FODNs) again. A 
common experience is that even when FODNs are stored in configuration 
files, they are resolved only once, when the application starts, and 
they are cached indefinitely thereafter. This is insufficient. Of 
course, this does not apply to all application software; for example, 
several well-known web browsers have short default cache lifetimes. 


There are even more egregious breaches of this principle, for 
example, software license systems that depend on the licensed host 


computer having a particular IP address. Other examples are the use 
of literal IP addresses in URLs, HTTP cookies, or application proxy 
configurations. (Also see Appendix A.) 


In contrast, there are also many application suites that actively 
deal with connectivity failures by retrying with alternative 
addresses or by repeating DNS lookups. This places a considerable 
burden of complexity on application developers. 


It should be noted that applications are in effect encouraged to be 
aware of and to store IP addresses by the very nature of the socket 
API calls gethostbyname() and getaddrinfo(). It is highly 
unfortunate that many applications use APIs that require the 
application to see and use lower-layer objects, such as network-layer 
addresses. However, the BSD Sockets API was designed and deployed 
before the Domain Name System (DNS) was created, so there were few 
good options at the time. This issue is made worse by the fact that 
these functions do not return an address lifetime, so that 
applications have no way to know when an address is no longer valid. 
The extension of the same model to cover IPv6 has complicated this 
problem somewhat. An application using the socket API is obliged to 
contain explicit logic if it wishes to benefit from the availability 
of multiple addresses for a given remote host. If a programming 
model were adopted in which only FODNs were exposed to applications, 
and addresses were cached with appropriate lifetimes within the API, 
most of these problems would disappear. It should be noted that at 
least the first part of this is already available for some 
programming environments. A common example is Java, where only FODNs 
need to be handled by application code in normal circumstances, and 
no additional application logic is needed to deal with multiple 
addresses, which are handled by the run-time system. This is highly 
beneficial for programmers who are not networking experts, and 
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insulates applications software from many aspects of renumbering. It 
would be helpful to have similarly abstract, DNS-oriented, Networking 
APIs openly specified and widely available for C and C++. 


Some web browsers intentionally violate the DNS TTL with a technique 
called "DNS Pinning." DNS Pinning limits acceptance of server IP 
address changes, due to a JavaScript issue where repeated address 
changes can be used to induce a browser to scan the inside of a 
firewalled network and report the results to an outside attacker. 
Pinning can persist as long as the browser is running, in extreme 
cases perhaps months at a time. Thus, we can see that security 
considerations may directly damage the ability of applications to 
deal with renumbering. 


Server applications might need to be restarted when the host they 
contain is renumbered, to ensure that they are listening on a port 
and socket bound to the new address. In an IPv6 multi-addressed 
host, server applications need to be able to listen on more than one 
address simultaneously, in order to cover an overlap during 
renumbering. Not all server applications are written to do this, and 
a name-based API as just mentioned would have to provide for this 
case invisibly to the server code. 


As noted in Section 2.6, the Service Location Protocol (SLP), and 
multicast DNS with SRV records for service discovery, have been 
available for some years. For example, many printers deployed in 
recent years automatically advertise themselves to potential clients 
via SLP. Many modern client operating systems automatically 
participate in SLP without requiring users to enable it. These tools 
appear not to be widely known, although they can be used to reduce 
the number of places that IP addresses need to be configured. 


5.2. Router-Related Issues 


[RFC2072] gives a detailed review of the operational realities in 
1997. A number of the issues discussed in that document were the 
result of the relatively recent adoption of classless addressing; 
those issues can be assumed to have vanished by now. Also, DHCP was 
a relative newcomer at that time, and can now be assumed to be 
generally available. Above all, the document underlines that 
systematic planning and administrative preparation are needed, and 
that all forms of configuration file and script must be reviewed and 
updated. Clearly this includes filtering and routing rules (e.g., 
when peering with BGP, but also with intradomain routing as well). 
Two particular issues mentioned in [RFC2072] are: 


o Some routers cache IP addresses in some situations. So routers 
might need to be restarted as a result of site renumbering. 
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o Addresses might be used by configured tunnels, including VPN 
tunnels, although at least the Internet Key Exchange (IKE) 
supports the use of Fully-Qualified Domain Names instead. 


On the latter point, the capability to use FODNs as endpoint names in 
IPsec VPNs is not new and is standard (see [RFC2407], Section 4.6.2.3 
and [RFC4306], Section 3.5). This capability is present in most 
IPsec VPN implementations. There does seem to be an "educational" or 
"awareness" issue that many system/network administrators do not 
realise that it is there and works well as a way to avoid manual 
modification during renumbering. (Of course, even in this case, a 
VPN may need to be reconnected after a renumbering event, but most 
products appear to handle this automatically.) 


In IPv6, if a site wanted to be multihomed using multiple provider- 
aggregated (PA) routing prefixes with one prefix per upstream 

provider, then the interior routers would need a mechanism to learn 
which upstream providers and prefixes were currently reachable (and 


valid). In this case, their Router Advertisement messages could be 
updated dynamically to only advertise currently valid routing 
prefixes to hosts. This would be significantly more complicated if 


the various provider prefixes were of different lengths or if the 
site had non-uniform subnet prefix lengths. 


5.3. Other Issues 
5.3.1. NAT State Issues 


When a renumbering event takes place, entries in the state table of 
any Network Address Translator that happen to contain the affected 
addresses will become invalid and will eventually time out. Since 
TCP and UDP sessions are unlikely to survive renumbering anyway, the 
hosts involved will not be additionally affected. The situation is 
more complex for multihomed SCTP [SCTPNAT], depending on whether a 
single or multiple NATs are involved. 


A NAT itself might be renumbered and might need a configuration 
change during a renumbering event. One of the authors has a NAT- 
enabled home gateway that obtains its exterior address from the 
residential Internet service provider by acting as a DHCP client. 
That deployment has not suffered operational problems when the ISP 
uses DHCP to renumber the gateway’s exterior IP address. A critical 
part of that success has been configuring IKE on the home gateway to 
use a "mailbox name" for the user’s identity type (rather than using 
the exterior IP address of the home gateway) when creating or 
managing the IP Security Associations. 
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5.3.2. Mobility Issues 


A mobile node using Mobile IP that is not currently in its home 
network will be adversely affected if either its current care-of 
address or its home address is renumbered. For IPv6, if the care-of 
address changes, this will be exactly like moving from one foreign 
network to another, and Mobile IP will re-bind with its home agent in 
the normal way. If its home address changes unexpectedly, it can be 
informed of the new global routing prefix used at the home site 
through the Mobile Prefix Solicitation and Mobile Prefix 
Advertisement ICMPv6 messages [RFC3775]. The situation is more 
tricky if the mobile node is detached at the time of the renumbering 
event, since it will no longer know a valid subnet anycast address 
for its home agent, leaving it to deduce a valid address on the basis 
of DNS information. 


In contrast to Mobile IPv6, Mobile IPv4 does not support prefix 
solicitation and prefix advertisement messages, limiting its 
renumbering capability to well-scheduled renumbering events when the 
mobile node is connected to its home agent and managed by the home 
network administration. Unexpected home network renumbering events 
when the mobile node is away from its home network and not connected 
to the home agent are supported only if a relevant Authentication, 
Authorisation, and Accounting (AAA) system is able to allocate 
dynamically a home address and home agent for the mobile node. 


5.3.3. Multicast Issues 


As discussed in [THINK], IPv6 multicast can be used to help rather 
than hinder renumbering, for example, by using multicast as a 
discovery protocol (as in IPv6 Neighbour Discovery). On the other 
hand, the embedding of IPv6 unicast addresses into multicast 
addresses specified in [RFC3306] and the embedded-RP (Rendezvous 
Point) in [RFC3956] will cause issues when renumbering. 


For both IPv4 and IPv6, changing the unicast source address of a 
multicast sender might also be an issue for receivers, especially for 
Source-Specific Multicast (SSM). Applications need to learn the new 
source addresses and new multicast trees need to be built 


For IPv4 or IPv6 with Any-Source Multicast (ASM), renumbering can be 
easy. If sources are renumbered, from the routing perspective, 
things behave just as if there are new sources within the same 
multicast group. There may be application issues though. Changing 
the RP address is easy when using Bootstrap Router (BSR) [RFC5059] 
for dynamic RP discovery. BSR is widely used, but it is also common 
to use static config of RP addresses on routers. In that case, 
router configurations must be updated too. 
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If any multicast ACLs are configured, they raise the same issue as 
unicast ACLs mentioned elsewhere. 


5.3.4. Management Issues 


Today, static IP addresses are routinely embedded in numerous 
configuration files and network management databases, including MIB 
modules. Ideally, all of these would be generated from a single 
central asset management database for a given site, but this is far 
from being universal practice. It should be noted that for IPv6, 
where multiple routing prefixes per interface and multiple addresses 
per interface are standard practice, the database and the 
configuration files will need to allow for this (rather than for a 
single address per host, as is normal practice for IPv4). 


Furthermore, because of routing policies and VPNs, a site or network 
might well embed addresses from other sites or networks in its own 
configuration data. (It is preferable to embed FODNs instead, of 
course, whenever possible.) Thus, renumbering will cause a ripple 
effect of updates for a site and for its neighbours. To the extent 
that these updates are manual, they will be costly and prone to 
error. Synchronising updates between independent sites can cause 
unpredictable delays. Note that Section 4 suggests that IPv6 ULAs 
can mitigate this problem, but of course only for VPNs and routes 
that are suitable for ULAs rather than globally routeable addresses. 
The majority of external addresses to be configured will not be ULAs. 


See Appendix A for an extended list of possible static or embedded 
addresses. 


Some address configuration data are relatively easy to find (for 
example, site firewall rules, ACLs in site border routers, and DNS). 
Others might be widely dispersed and much harder to find (for 
example, configurations for building routers, printer addresses 
configured by individual users, and personal firewall 
configurations). Some of these will inevitably be found only after 
the renumbering event, when the users concerned encounter a problem. 


The overlapped model for IPv6 renumbering, with old and new addresses 
valid simultaneously, means that planned database and configuration 
file updates will proceed in two stages -- add the new information 
some time before the renumbering event, and remove the old 
information some time after. All policy rules must be configured to 
behave correctly during this process (e.g., preferring the new 
address as soon as possible). Similarly, monitoring tools must be 
set up to monitor both old and new during the overlap. 
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However, it should be noted that the notion of simultaneously 
operating multiple prefixes for the same network, although natural 
for IPv6, is generally not supported by operational tools such as 
address management software. It also increases the size of IGP 
routing tables in proportion to the number of prefixes in use. For 
these reasons, and due to its unfamiliarity to operational staff, the 
use of multiple prefixes remains rare. Accordingly, the use of ULAs 
to provide stable on-site addresses even if the off-site prefix 
changes is also rare. 


If both IPv4 and IPv6 are renumbered simultaneously in a dual-stack 
network, additional complications could result, especially with 
configured IP-in-IP tunnels. This scenario should probably be 
avoided. 


Use of FODNs rather than raw IP addresses wherever possible in 
configuration files and databases will reduce/mitigate the potential 
issues arising from such configuration files or management databases 
when renumbering is required or otherwise occurs. This is advocated 
in [RFC1958] (point 4.1). Just as we noted in Section 5.1.4 for 
applications, this is insufficient in itself; some devices such as 
routers are known to only resolve FQDNs once, at start-up, and to 
continue using the resulting addresses indefinitely. This may 
require routers to be rebooted, when they should instead be resolving 
the FODN again after a given timeout. 


By definition, there is at least one place (i.e., the DNS zone file 
or the database from which it is derived) where address information 
is nevertheless inevitable. 


It is also possible that some operators may choose to configure 
addresses rather than names, precisely to avoid a possible circular 
dependency and the resulting failure modes. This is arguably even 
advocated in [RFC1958] (point 3.11). 


It should be noted that the management and administration issues 
(i.e., tracking down, recording, and updating all instances where 
addresses are stored rather than looked up dynamically) form the 
dominant concern of managers considering the renumbering problem. 
This has led many sites to continue the pre-CIDR (Classless Inter- 
Domain Routing) approach of using a provider-independent (PI) prefix. 
Some sites, including very large corporate networks, combine PI 
addressing with NAT. Others have adopted private addressing and NAT 
as a matter of choice rather than obligation. This range of 
techniques allows for addressing plans that are independent of the 
ISP (s) in use, and allows a straightforward approach to multihoming. 
The direct cost of renumbering is perceived to exceed the indirect 
costs of these alternatives. Additionally, there is a risk element 
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stemming from the complex dependencies of renumbering: it is hard to 
be fully certain that the renumbering will not cause unforeseen 
service disruptions, leading to unknown additional costs. 


A relevant example in a corporate context is VPN configuration data 
held in every employee laptop, for use while on travel and connecting 
securely from remote locations. Typically, such VPNs are statically 
configured using numeric IP addresses for endpoints and even with 
prefix lists for host routing tables. Use of VPN configurations with 
FODNs to name fixed endpoints, such as corporate VPN gateways, and 
with non-address identity types would enable existing IP Security 
with IKE to avoid address renumbering issues and work well for highly 
mobile users. This is all possible today with standard IPsec and 
standard IKE. It just requires VPN software to be configured with 
names instead of addresses, and thoughtful network administration. 


It should be noted that site and network operations managers are 
often very conservative, and reluctant to change operational 
procedures that are working reasonably well and are perceived as 
reasonably secure. They quite logically argue that any change brings 
with it an intrinsic risk of perturbation and insecurity. Thus, even 
if procedural changes are recommended that will ultimately reduce the 
risks and difficulties of renumbering (such as using FODNs protected 
by DNSsec where addresses are used today), these changes might be 
resisted. 


5.3.5. Security Issues 


For IPv6, addresses are intended to be protected against forgery 
during neighbour discovery by SEcure Neighbour Discovery (SEND) 
[RFC3971]. This appears to be a very useful precaution during 
dynamic renumbering, to prevent hijacking of the process by an 
attacker. Any automatic renumbering scheme has a potential exposure 
to such hijacking at the moment that a new address is announced. 
However, at present it is unclear whether or when SEND might be 
widely implemented or widely deployed. 


Firewall rules will certainly need to be updated, and any other cases 
where addresses or address prefixes are embedded in security 
components (access control lists, AAA systems, intrusion detection 
systems, etc.). If this is not done in advance, legitimate access to 
resources might be blocked after the renumbering event. If the old 
rules are not removed promptly, illegitimate access might be possible 
after the renumbering event. Thus, the security updates will need to 
be made in two stages (immediately before and immediately after the 
event). 
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6. 


6. 


There will be operational and security issues if an X.509v3 Public 
Key Infrastructure (PKI) Certificate includes a subjectAltName 
extension that contains an iPAddress [RFC5280], and if the 
corresponding node then undergoes an IP address change without a 
concurrent update to the node’s PKI Certificate. For these reasons, 
use of the dNSName rather than the iPAddress is recommended for the 
subjectAltName extension. Any other use of IP addresses in 
cryptographic material is likely to be similarly troublesome. 


If a site is, for some reason, listed by IP address in a white list 
(such as a spam white list), this will need to be updated. 
Conversely, a site that is listed in a black list can escape that 
list by renumbering itself. 


The use of IP addresses instead of FODNs in configurations is 
sometimes driven by a perceived security need. Since the name 
resolution process has historically lacked authentication, 
administrators prefer to use raw IP addresses when the application is 
security sensitive (firewalls and VPN are two typical examples). It 
might be possible to solve this issue in the next few years with 
DNSsec (see Section 2.5), now that there is strong DNS Security 
deployment momentum. 


Proposed Mechanisms 
1. SHIM6 


SHIM6, proposed as a host-based multihoming mechanism for IPv6, has 
the property of dynamically switching the addresses used for 
forwarding the actual packet stream while presenting a constant 
address as the upper-layer identifier for the transport layer 
[RFC5533]. At least in principle, this property could be used during 
renumbering to alleviate the problem described in Section 5.1.2. 


SHIM6 is an example of a class of solutions with this or a similar 
property; others are Host Identity Protocol (HIP), IKEv2 Mobility and 
Multihoming (MOBIKE), Mobile IPv6, SCTP, and proposals for multi-path 
TCP. 


.2. MANET Proposals 


The IETF working groups dealing with mobile ad hoc networks have been 
working on a number of mechanisms for mobile routers to discover 
available border routers dynamically, and for those mobile routers to 
be able to communicate that information to hosts connected to those 
mobile routers. 
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Recently, some MANET work has appeared on a "Border Router Discovery 
Protocol (BRDP)" that might be useful work towards a more dynamic 
mechanism for site interior router renumbering [BRDP]. 


At present, the IETF AUTOCONF WG 
(http://www.ietf.org/html.charters/autoconf-charter.html) is working 
on address autoconfiguration mechanisms for MANET networks that also 
seem useful for ordinary non-mobile non-MANET networks [AUTOC]. This 
work is extensively surveyed in [AUTOC2] and [AUTOC3]. Other work in 
the same area, e.g., [RFC5558], might also be relevant. 


MANETS are, of course, unusual in that they must be able to 
reconfigure themselves at all times and without notice. Hence, the 
type of hidden static configurations discussed above in Section 5.3.4 
are simply intolerable in MANETs. Thus, it is possible that when a 
consensus is reached on autoconfiguration for MANETs, the selected 
solution(s) might not be suitable for the more general renumbering 
problem. However, it is certainly worthwhile to explore applying 
techniques that work for MANETs to conventional networks also. 


6.3. Other IETF Work 


A DHCPv6 extension has been proposed that could convey alternative 
routes, in addition to the default router address, to IPv6 hosts 
[DHRTOPT]. Other DHCP options are also on the table that may offer 
information about address prefixes and routing to DHCP or DHCPv6 
clients, such as [DHSUBNET] and [DHMIFRT]. It is conceivable that 
these might be extended as a way of informing hosts dynamically of 
prefix changes. 


In the area of management tools, Network Configuration (NETCONF) 
Protocol [RFC4741] is suitable for the configuration of any network 
element or server, so could in principle be used to support secure 
remote address renumbering. 


The DNSOP WG has considered a Name Server Control Protocol (NSCP) 
based on NETCONF that provides means for consistent DNS management 
including potential host renumbering events [DNSCONT]. 


6.4. Other Proposals 


A proposal has been made to include an address lifetime as an 
embedded field in IPv6 addresses, with the idea that all prefixes 
would automatically expire after a certain period and become 
unrouteable [CROCKER]. While this might be viewed as provocative, it 
would force the issue by making renumbering compulsory. 
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7. Gaps 


This section seeks to identify technology gaps between what is 
available from existing open specifications and what appears to be 
needed for site renumbering to be tolerable. 


7.1. Host-Related Gaps 


It would be beneficial to expose address lifetimes in the socket API, 
or any low-level networking API. This would allow applications to 
avoid using stale addresses. 


The various current discussions of a name-based transport layer or a 
name-based network API also have potential to alleviate the 
application-layer issues noted in this document. Application 
development would be enhanced by the addition of a more abstract 
network API that supports the C and C++ programming languages. For 
example, it could use FODNs and Service Names, rather than SockAddr, 
IP Address, protocol, and port number. This would be equivalent to 
similar interfaces already extant for Java programmers. 


Moving to a FODN-based transport layer might enhance the ability to 
migrate the IP addresses of endpoints for TCP/UDP without having to 
interrupt a session, or at least in a way that allows a session to 
restart gracefully. 


Having a single registry per host for all address-based configuration 
(/etc/hosts, anyone?), with secure access for site network 
management, might be helpful. Ideally, this would be remotely 
configurable, for example, leveraging the IETF’s current work on 
networked-device configuration protocols (NetConf). While there are 
proprietary versions of this approach, sometimes based on Lightweight 
Directory Access Protocol (LDAP), a fully standardised approach seems 
desirable. 


Do we really need more than DHCP or SLAAC for regular hosts? Do we 
need an IPv4 equivalent of SLAAC? How can the use of DHCP FORCERENEW 
and DHCPv6 RECONFIGURE for bulk renumbering be deployed? FORCERENEW 
in particular requires DHCP authentication [RFC3118] to be deployed. 


The IETF should resolve the ’IPv6 ND M/O flag debate’ once and for 
all, with default, mandatory and optional behaviours of hosts being 


fully specified. 


The host behaviour for upstream link learning suggested in 
Section 2.3 should be documented. 
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It would be helpful to have multi-path, survivable, extensions for 
both UDP and TCP (or institutionalise some aspects of SHIM6). 


7.2. Router-Related Gaps 


A non-proprietary secure mechanism to allow all address-based 
configuration to be driven by a central repository for site 
configuration data. NETCONF might be a good starting point. 


A MANET solution that’s solid enough to apply to fully operational 
small to medium fixed sites for voluntary or involuntary renumbering. 


A MANET-style solution that can be applied convincingly to large or 
very large sites for voluntary renumbering. 


A useful short-term measure would be to ensure that [RFC2894] and 
[RFC3633] can be used in practice. 


7.3. Operational Gaps 


Since address changes are usually communicated via the DNS, the 
latter’s security is essential for secure renumbering. Thus, we 
should continue existing efforts to deploy DNSsec globally, including 
not only signing the DNS root, DNS TLDs, and subsidiary DNS zones, 
but also widely deploying the already available DNSsec-capable DNS 
resolvers. 


Similarly, we should document and encourage widespread deployment of 
Secure Dynamic DNS Update both in DNS servers and also in both client 


and server operating systems. This capability is already widely 
implemented and widely available, but it is not widely deployed at 
present. 


Deploy multi-prefix usage of IPv6, including Unique Local Addresses 
(ULAs) to provide stable internal addresses. In particular, address 
management tools need to support the multi-prefix model and ULAs. 


Ensure that network monitoring systems will function during 
renumbering, in particular to confirm that renumbering has completed 
successfully or that some traffic is still using the old prefixes. 


Document and encourage systematic site databases and secure 
configuration protocols for network elements and servers (e.g., 
NETCONF). The database should store all the information about the 
network; scripts and tools should derive all configurations from the 
database. An example of this approach to simplify renumbering is 
given at [LEROY]. 
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Document functional requirements for site renumbering tools or 
toolkits. 


Document operational procedures useful for site renumbering. 


In general, document renumbering instructions as part of every 
product manual. 


Recommend strongly that all IPv6 deployment plans, for all sizes of 
site or network, should include provision for future renumbering. 
Renumbering should be planned from day one when the first lines of 
the configuration of a network or network service are written. Every 
IPv6 operator should expect to have to renumber the network one day 
and should plan for this event. 


7.4. Other Gaps 
Define a secure mechanism for announcing changes of site prefix to 
other sites (for example, those that configure routers or VPNs to 


point to the site in question). 


For Mobile IP, define a better mechanism to handle change of home 
agent address while mobile is disconnected. 


8. Security Considerations 
Known current issues are discussed in Section 5.3.5. Security issues 
related to SLAAC are discussed in [RFC3756]. DHCP authentication is 


defined in [RFC3118]. 


For future mechanisms to assist and simplify renumbering, care must 
be taken to ensure that prefix or address changes (especially changes 
coming from another site or via public sources such as the DNS) are 
adequately authenticated at all points. Otherwise, misuse of 
renumbering mechanisms would become an attractive target for those 
wishing to divert traffic or to cause major disruption. As noted in 
Section 5.1.4, this may result in defensive techniques such as "DNS 
pinning", which create difficulty when renumbering. 


Whatever authentication method(s) are adopted, key distribution will 
be an important aspect. Most likely, public key cryptography will be 
needed to authenticate renumbering announcements passing from one 
site to another, since one cannot assume a preexisting trust 
relationship between such sites. 
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Appendix A. Embedded IP Addresses 


This Appendix lists common places where IP addresses might be 
embedded. The list was adapted from [THINK]. 


Provider based prefix(es) 
Names resolved to IP addresses in firewall at startup time 


IP addresses in remote firewalls allowing access to remote 
services 


IP-based authentication in remote systems allowing access to 
online bibliographic resources 


IP address of both tunnel end points for IPv6 in IPv4 tunnel 
Hard-coded IP subnet configuration information 
IP addresses for static route targets 

Blocked SMTP server IP list (spam sources) 

Web .htaccess and remote access controls 
Apache .Listen. directive on given IP address 
Configured multicast rendezvous point 

TCP wrapper files 

Samba configuration files 

DNS resolv.conf on Unix 

Any network traffic monitoring tool 

NIS/ypbind via the hosts file 

Some interface configurations 

Unix portmap security masks 

NIS security masks 


PIM-SM Rendezvous Point address on multicast routers 
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